Hey, did you know that I'm a Microsoft MVP? As an MVP, sometimes Microsoft lets me do some cool stuff.

For instance, they let me write some blog posts about Couchbase with Windows and .NET for the MVP Award Program Blog! There are three total parts, and part 1 was just published.

So go check it out, subscribe to the MVP Award Blog, and most importantly, download Couchbase and try it out today.

I always want to thank fellow MVP Travis Smith for being the technical editor for these posts! He provided some great feedback, and he's an overall great guy!

I'm trying to familiarize myself with node.js, since it seems to be in use by a lot of Couchbase customers. I heard that Visual Studio code had some pretty good node.js support built in, so I decided to give it a shot.

I already had node and npm installed on my Windows machine. I don't remember why. If you aren't sure if you do, open up Powershell (or cmd) and try:

node --version

and

npm --version

(If metaphors help you, I think of node as ASP.NET and I think of npm as NuGet)

If neither of those commands works, then you can install node with Chocolatey NuGet: choco install nodejs

The next easiest thing you can do is create a file with text editor, say "app.js". Put this into that file:

var msg = "Hello, world!";
console.log(msg);

Woo. Now back at the command line, type:

node app.js

And guess what it will write out? If you guessed "Hello, world!" then give yourself 10 points.

So, what good is this? Well, you can now write programs in JavaScript outside of a browser. A lot of people use this to write server-side JavaScript, for example. They might use a framework like Express (which, back to the metaphors, I think of as ASP.NET MVC). You can use npm to install express and an npm "start" command to run your Express app. I may blog more about that later, after I play with it some more.

I have a web page on domain A and, say, a Json endpoint on domain B. I would like domain A to make an Ajax request to domain B, but when I try that, I get an error message, as shown here:

Some options:

• Make the request server-side instead of client side.
• If you have control of the endpoint, add "Access-Control-Allow-Origin" to the response header.
• Use jsonp (you may still need control of the endpoint if it doesn't support jsonp already).

Let's explore the jsonp option. Here's a similar request to the one above, except this time it's using jsonp.

It does not raise an error.

The way jsonp works is a little wacky, but the main thing you need to know is that you need to specify a callback function. jQuery handles this automatically on the client side. Here's how I handle it on the server side with ASP.NET MVC using the Mvc.Jsonp package.

Notice three things:

1. SomeController inherits from JsonpControllerBase
2. GetAllItems return type is JsonpResult and has a "callback" string parameter
3. The Jsonp function from the base class and how callback is passed to it.

The benefit is that you can now do cross-domain scripting. So far the drawbacks seems to be that:

• It's limited to GET requests
• Error handling may take some extra work
• If there is no Jsonp endpoint, then you either have to make one or you're out of luck.

I'm giving it a shot on Ledger, and seems to be working fine so far.

Based on a Twitter conversation with Seth Petry-Johnson about mocking/faking SqlException objects in .NET, I decided to go ahead and put what I had written into an open-source project on GitHub. I didn't spend much time on the name: I thought about Sharp Stick and Pointy Stick, but those repo names have already been taken! So, I thought about "stick" some more and remembered the famous line from Lady Macbeth: "screw your courage to the sticking place". Well, I guess I don't have much of a future in professional naming.

Since I was creating a repo anyway, I thought I'd throw a couple of other helpers in there. I put in some of my favorite ASP.NET / ASP.NET MVC helpers and an obscure little string helper. I'm not trying to remake PGK Extensions or anything--just putting some stuff out there that might help someone.

I should also note that the SqlExceptionHelper stuff isn't entirely original: I borrowed some code from a 2006 blog post by Rido, and just updated the reflection code since the private constructor has changed since then (and could possibly change again, since it's a private constructor in a sealed class).

Anyway, go check out Sticking Place on GitHub and let me know what you think.

In a project that I'm working on, I'm using Dapper for data access and I'm using StructureMap as my IoC containter. It's an ASP.NET MVC project.

I was recently demoing the project to my partner on the staging site (Azure), and I ran into a troubling error having to do with data connections (that I had not experienced running it locally on IIS yet). I immediately thought that it must be an issue with the SQL connections (SqlDbConnection objects that implement the IDbConnection interface, per Dapper) not being closed and/or disposed of correctly.

I remember encountering the same issue when I was developing this very site that you are reading, and the solution is to use the HttpContext scope within StructureMap when configuring it for the IDbConnection interface.

Here's what I started with:

And here's what I refactored it to:

I just added HttpContextScoped (the default is PerRequest scope, see StructureMap docs on Scoping and Lifecycle Management). I also added the ReleaseAndDisposeAllHttpScopedObjects to Global.asax.cs, so that StructureMap would...release and dispose those objects at the end of each request.

However, when I did that, I was still getting problems. I would get exceptions saying that the SqlConnection ConnectionString was the empty string. Something wasn't right. I did some searching around about the issue in the docs, and couldn't really find what I was looking for. I did come across someone with a similar issue on StackOverflow, also trying to understand HttpContextScoped. The top answer from PHeiberg (not the accepted answer) pointed me the right direction.

I used a lambda expression instead of just passing the SqlConnection directly. So now my SqlDbConnections are scoped to the HttpContext, and will be cleaned up after every request. That should squash the issue I was seeing on the staging stie.